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(57) Abstract: A method for distributing private keys and certificates to cryptographic devices (1). According to the invention the 
method comprises the steps of: providing a first CA-system (5) at the manufacture of the devices; providing a temporary private key 
and a temporary certificate from the first CA-system (5) to each device (1) during the manufacturing of the device (1); delivering 
said devices (1) to customers; providing a second CA-system (11) at a customer node (10), this being performed at this process 
step or earlier in the process; for each delivered cryptographic device: connecting the device to a network, which is reachable from 
the customer node (10); authenticating the device as being from said manufacture; automatically replacing the temporary private 
key and the temporary certificate with a new private key and a new certificate and also automatically providing the device with a 
CA-certificate, the new certificates being signed by the second CA-system (11) which is notified of the connection of the device (1) 
as soon as the device (1) has connected to the network. 
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TECHNICAL FIELD OF THE INVENTION 

5 The present invention relates to a method for distributing private keys and certificates 
to cryptographic devices. 

It also relates to a system used to distribute private keys and certificates to crypto- 
graphic devices. 

10 

Furthermore it relates to a cryptographic device. 
RELATED ART 



1 5 Data traffic over insecure networks, such as Internet, is an area where encryption and 
authentication become more and more common. In many devices it is critical to know 
whom one is communicating with and it is also critical to know that information re- 
ceived not has been changed by someone who is unauthorised. Examples of such de- 
vices are an e-box, a BSC (Base Station Controller) or any device which is connected 

20 to an insecure network and is being used for electronic commerce, bank services, con- 
trol, supervision etc. These devices need security mechanisms such as authentication, 
integrity and maybe confidentiality. 

For a security solution to work the usage of asymmetric keys are required. The sender 
25 of an authenticated message uses its private key to provide authenticity of the message 
and the receiver applies the sender's public key to verify the message. 



30 



The way the private and public keys are distributed and used is called a Public Key In- 
frastructure (PKI). The present invention discloses a method to distribute the keys in 
an effective and secure way. 
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A private key and its corresponding public key (a key pair) can either be generated by 
the device itself or by a central body and then be distributed to the device. 

For a certain security solution to work, a certain public key must be connected to the 
5 correct identity. If central distribution of keys is used the device's public key is stored, 
in a directory. Every time an authentication is performed or when a confidential mes- 
sage is to be sent, the correct public key is retrieved from the directory. The main . 
problems with this method are the administrative issues regarding populating the di- 
rectory and keeping the integrity of the information stored. A common solution to this 
10 is to generate X.509 certificates, where a public key and its corresponding identity is 
stored in an electronic document and then digitally signed by an Certification Author- 
ity (CA). The signature will prevent the manipulation of the information in the certifi- 
cate. 

15 Since the X.509 certificate does not include any secret information, it can be transmit- 
ted together with e.g. a signed message or during the handshake phase of SSL-(Secure 
Socket Layer)-communication. This will make all the PKI-based security solutions 
easy to handle. 

20 A certificate is verified in the same way as a normal signed document. All units having 
access to the issuer's public key are able to verify the certificate. The issuer is the CA- 
system, which has signed the certificate. The issuer's public key is also included in a 
certificate called root-certificate or CA-certificate. 

25 Authentication is a security mechanism in which a stated identity (or role) is proven. 
There are mainly two types of authentication; weak and strong authentication. The two 
types differ in the way the identity is proven. The commonly used way in weak 
authentication is that a static password (or similar) is connected to an identity and input 
when the authentication is required. The commonly used way in strong authentication 

30 is that the password connected to the identity is "random" (from an intruder's point of 
view) and the same password is never entered or sent twice. The "random" password is 
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often the result of a symmetric or asymmetric encryption, with the latter being the most 
common in new solutions. To be able to perform two-way strong authentication the 
server side and client side need to possess a private key, certificate and CA-certificate. 

5 To be able to perform server strong authentication, the server side must possess a pri- 
vate key and a certificate. When the client generates a challenge, which is sent to the 
server, the server encrypts the challenge with the server's private key. The encrypted 
challenge is sent back to the client together with the server certificate. The client veri- 
fies the received certificate using the CA-certificate. The answer is decrypted with the 
10 servers public key included in the certificate and if the decrypted answer equals the., 
sent challenge the connection is accepted. Client authentication is performed in the 
same way but this time the client needs a private key and a certificate and the CA- 
certificate has to be present in the server. 

15 Authentication is not limited to physical users but can also be performed between two 
machines or applications. 

Here below some important words relating to security will be described: 

20 i) Authorization or access control is the mechanism in which an access to a certain re- 
source is granted or not. 

ii) Integrity of the data passed is often essential to two communicating parties. This 
means that a receiver of the data wants to be certain that the data received is consistent 

25 with the data that was sent. 

iii) Confidentiality protects against disclosure to unauthorised identities. 



30 



iv) The Non-repudiation security service prevents that someone falsely denies that a 
transaction or a communication has occurred. This is often called digital signature 
since the Non-repudiation service can be used to generate a digital correspondence to a 
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normal non-digital and signed document. Non-repudiation is a combination of authen- 
tication and integrity, i.e. the identity of the sender of the data is established and the 
data received is consistent with the data sent. 

5 . v) Signing/verification comprises authentication, integrity and the feature that the 
sender not is able to deny a sent message. The sender is signing the message and the 
receiver is verifying the message. 

Much of the security in the described security services depends on the user or device 
10 control of the private key used in the services. If a private key used in, e.g., an authen- 
tication procedure is not under control of the user or device that is subject to the 
authentication, the authentication can easily be forged.- This is the same for all security 
services. 

15 Http (Hyper-Text Transfer Protocol) can use SSL to secure all traffic that is passed 
through a certain TCP(Transmission Control Protocol) socket. This is called https 
(Hyper-Text Transfer Protocol, Secure variant). When the SSL-connection is estab- 
lished and data is passed over to the server application a handshake phase is executed. 
In this phase encryption keys are exchanged and authentication is performed. 

20 

The private keys and certificates could be saved in a number of different ways. Hard 
smart cards and soft smart cards, i.e. a software file, are the two most common ways. A 
hard smart card is a tamper resistant device on which the key and certificate are stored. 
The device executes the algorithm internally. With this method, the private key will 

25 never leave its protected storage. The key is protected on the smart card and it can be 
distributed in an arbitrary way to the customer. Using a soft smart card means that the 
private key is stored in an ordinary software file, e.g. PKCS12-file, PEM-file etc. 
However an entity's private key must be protected from disclosure and unauthorised 
usage and this is most commonly accomplished by encrypting the private key using a 

30 password (a pass-phrase) as the encryption/decryption key. 
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It is important that the private key is protected from disclosure during manufacturing, 
distribution and when the private key is loaded in the device. The private key must also 
be protected from disclosure inside the device. Another problem related to private keys 
and certificates is customization. Customization means the procedure to connect a de- 
5 vice to a specific customer. Normally, the device is customized at the time when the 
device gets its private key. 

Solutions using hard smart cards suffer from the drawback that these solutions end up 
to be very expensive. The card itself may not be very expensive but you need also to 

1 0 have a reader for the hard smart card and software to be able to read from the card etc. 
There are different solutions using soft smart cards present today. One problem with 
these solutions is the lack of security. One today common way to store the files and 
distribute them is to store them on a floppy disk and then insert the disks in the de- 
vices. This method is not as secure as desirable and the method is also rather costly. 

1 5 Someone unauthorised could get hold of a disk and the manually inserting of the disk 
into the device is expensive. 

SUMMARY 

20 One object of the present invention is to provide a security architecture that solves the 
distribution and customization problems in a new way that is less expensive than the 
known solutions. 

It is also an object of the invention to provide a security architecture that solves the 
25 distribution and customization problems in a new way that is effective, secure and 
automatic. 

*■ 

These objects are achieved in a method as described initially that comprises the steps 
of: 

30 - providing a first CA-system at the manufacture of the devices; 
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- providing a temporary private key and a temporary certificate from the first CA- 
system to each device during the manufacturing of the device; 

- delivering said devices to customers; 

- providing a second CA-system at a customer node, this being performed at this 
5 process step or earlier in the process; 

for each delivered cryptographic device: 

- connecting the device to a network, which is reachable from the customer node; 

- authenticating the device as being from said manufacture; 

- automatically replacing the temporary private key and the temporary certificate 
10 with a new private key and a new certificate and also automatically providing the 

device with a CA-certificate, the new certificates being signed by the second CA- 
system which is notified of the connection of the device as soon as the device has 
connected to the network. 

15 The objects are also achieved by a system as initially described, which comprises: 

- a first CA-system located at the manufacture of the devices, which first CA-system 
is adapted to provide the device with a temporary private key and a temporary cer- 
tificate during the manufacture of the device; 

- a second CA-system, being the customer's CA-system, located in a customer node, 
20 which is reachable from the device when it has been connected to a network by, 

for example the end user, said second CA-system being adapted to provide the de- 
vice with a new private key, a new certificate which is signed by the second CA- 
system and with a CA-certificate, said new private key and new certificate being 
adapted to automatically replace the temporary private key and the temporary cer- 
25 tificate in the device when the device is being customized; 

- an authentication module being adapted to verify that the device has been produced 
at said manufacture by using a factory CA-certificate provided to the authentication 
module from the first CA-system. 

30 The objects are also achieved in a cryptographic device, which is adapted to receive a 
temporary private key and a temporary certificate from a first CA-system provided at 



WO 02/065696 PCT/SE02/00243 

7 

the site of manufacture during the manufacture of the device. Furthermore the device 
comprises an activating client, which is adapted to be activated as soon as the device is 
connected to a network and an address to a customer node has been provided. The ac- 
tivating client is adapted to replace the temporary private key and the temporary cer- 
5 tificate with a new private key, a new certificate and a CA-certificate, the certificates 
being signed by a second CA-system comprised in the customer node, which is reach- 
able from the network. 

When this method, system and device are used, the distribution of private keys and 
1 0 certificates to cryptographic devices and the customization of the devices are per- 
formed automatically. 

Preferably the method further comprises the steps of: 

- loading software, for example a first CA-client, which is adapted to send out a re- 
1 5 quest for the temporary private key and the temporary certificate to the first CA- 
system, in the device by using a loading station provided at the site of manufacture 
during the manufacture; 

- indicating to the device from the loading station that it is time to request a tempo- 
rary private key and a temporary certificate from the fist CA-system; 

20 - sending the request from the device to the first CA-system as an xml-(extensible 
mark-up language)-request; 

- storing the retrieved temporary private key and temporary certificate in the device. 

Hereby the distribution of a temporary private key and a temporary certificate during 
25 the manufacture of the device is performed automatically. 

Advantageously the method further comprises the steps of: 

- automatically sending out a request for a new private key, a new certificate and a 
CA-certificate from the device to the customer node as soon as the device has been 

30 connected to the network and the address to the customer node has been provided; 
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- authenticating the device in an authentication module comprised in the customer 
node by using a factory CA-certificate provided to the authentication module from 
the first CA-system; 

- if the authentication was successful, forwarding the request to an authorization 

5 module connected to the authentication module, to verify if the request should be 

allowed and the device should be provided with new keys and certificates from the 
second CA-system; 

- if the authorization was successful, forwarding the request to a second CA-client, 
which forwards the request as an xml-request to the second CA-system, which is 

10 ' connected to the second CA-client; 

- answering with a new private key, a new signed certificate and also with a CA- 
certificate from the second CA-system; 

- forwarding the. answer to the requesting device; 

- replacing the temporary private key and the temporary certificate with the new pri- 
15 vate key and the new certificate and storing them together with the CA-certificate 

in the device. 

Hereby the distribution of a new private key, a new certificate and a CA-certificate is 
performed automatically. Also the customization of the device is performed automati- 
20 cally. The distribution is also secure. 

Alternatively the method further comprises the steps of: 

- providing the device with a CA-certificate from the first CA-system during the 
manufacture; 

25 - automatically sending out a request for a new private key, a new certificate and a 
CA-certificate from the device to the customer node as soon as the device has been 
• connected to the network and the address to the customer node has been provided; 

- authenticating the device in an authentication module comprised in the customer 
node by using a factory CA-certificate provided to the authentication module from 

30 the first CA-system; 
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- authenticating the customer node in the device by using the CA-certificate provided 
to the device during the manufacture; 

- if the authentication in the customer node and the device was successful, forward- 
ing the request to an authorization module comprised in the customer node to verify 
if the request should be allowed and the device should be provided with new keys 
and certificates from the second CA-system; 

- if the authorization was successful, forwarding the request to a second CA-client, 
which forwards the request as an xml-request to the second CA-system, which is 
connected to the second CA-client; 

. - answering with a new private key, a new signed certificate and also with a CA- 
certificate from the second CA-system; 

- forwarding the answer to the requesting device; 

- replacing the temporary private key and the temporary certificate with the new pri- 
vate key and the new certificate and storing them together with the CA-certificate 
in the device. 

Hereby a two way authentication is performed. 

Preferably the method further comprises the steps of: 

- sending the request from the device through a communication means provided in 
the device; • 

- signing the request in the communication means using the temporary private key 
before it is sent to the customer node; 

- encrypting the request by the communication means before it is sent to the cus- 
tomer node; 

- receiving and decrypting the answers from the second CA-system in the communi- 
cation means. 

Suitably the method comprises decrypting the request in an authentication module 
when the request from the device is received in the customer node and encrypting the 
answer in the authentication module before it is sent to the device. 
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Furthermore the method suitably comprises including the identity of the device and 
optional parameters in the request, this identity and the parameters being used in the 
configuration of the certificate. 
5 . 
Preferably the method further comprises the steps of: 

- receiving a request for a new private key, a new certificate and a CA-certificate 
from the device in the second CA-system; 

- generating a new private key, a new public key and configuring a new certificate 
10 comprising said new public key in the second CA-system; 

- . signing said new certificate and a CA-certificate in the second CA-system; 

- automatically answering the request by sending the requested new private key, new 
certificate and CA-certificate to the device from the second CA-system. 

15 Hereby the process in the second CA-system also is performed automatically. 

Suitably the communication means is a https-proxy and the authentication module is a 
https-server. Hereby https could be used as the communication protocol. 

20 BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a schematic view of the process for manufacturing devices according to the 
invention. 

25 Fig. 2 is a schematic view of a network to which devices are connected. 

Fig. 3 is a flowchart of one embodiment of a process according to the invention. 

Fig. 4 is a schematic view of a CA(Certification Authority)-system according to the 
30 invention. 
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Fig. 5 is a schematic view of a device according to the invention. 

DETAILED DESCRIPTION OF EMBODIMENTS 

5 The present invention discloses a software solution to the security problem. The neces- 
sary private keys and the certificates are stored in one or several software files. 

Fig. 1 is a schematic view of the process for manufacturing devices according to the 
invention. A number of devices 1 are shown. They comprise all a first 

10 CA(Certification Authority)-client 3. A CA-client is in this application defined to be 
means for automatically creating a request of a private key, a certificate and optionally 
a CA-certificate from a CA-system. The first CA-clients 3 are in contact with a first 
CA-system 5 provided at the site of manufacture here called a factory. The network 
between the devices and the first CA-system 5, in the factory is a "secure network". A 

1 5 "secure network" is here a private network to which no one that is unauthorised has 
access. The devices 1 are also connected to a loading station 4 through a "secure net- 
work". This loading station 4 has two important functions. The first is to load software, 
for example the first CA-client 3, to the devices 1 and the second is to inform the de- 
vice 1 of when it is time to make the request for a private key and a certificate. 

20 

The devices are cryptographic devices. They include at least one private key and a cer- 
tificate, which are used for signing/verification. A cryptographic device is a device, 
which comprises software for encrypting and decrypting and possibly also software for 
performing digital signing/verification. The device could for example be an e-box, a 
25 set-top-box, a BSC (Base Station Controller) or any device which needs private keys 
and certificates for signing/verification and/or encryption/decryption. . 

When the loading station 4 has informed the device 1 that it is time to make a request, 
the first CA-client 3 in the device 1 automatically requires a first temporary private key 
30 and a first temporary certificate and optionally a CA-certificate from the first CA- 
system 5. The request is sent over a TCP/IP and it includes the identity of the device 
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and some optionally parameters such as the length of the keys, the validity of the cer- 
tificate, the name of the CA-server etc. These parameters are used in the configuration 
of the certificate. The keys are given the specified length and some of the other pa- 
rameters are included in the certificate. If no optionally parameters are provided from 
5 the device the CA-system uses default values. The first C A- system 5 generates a pri- 
vate key and a public key. The public key is included in a certificate and the certificate 
is signed by the CA-system. The CA-system then transfers the key and the certificate 
to the first CA-client 3. Optionally a CA-certificate could also be provided to the de- 
vice 1 . The device 1 stores the key and certificate/s and comprises thus a first tempo- 
10 rary private key and a first temporary signed certificate and optionally a CA-certificate 
when it leaves the factory. The devices are not tied to a specific customer when they 
leave the factory. The connection to a specific customer is established first when the 
temporary key and certificate are replaced by new ones provided from a customer CA- 
system. This is described further down in the description. 

15 

In an alternative embodiment the first CA-client 3 is positioned outside the devices 1 
in the factory. This CA-client could then be used by more than one device 1 to request 
temporary keys and certificates during the manufacture. 

20 Fig. 2 is a schematic view of a network given as an example to which the device 1 
could be connected. The device 1 is connected to a customer node 10 via one or sev- 
eral networks 12 and optionally via one or several hosts (e.g. fire wall). The networks 
could be insecure networks such as Internet. 

25 The customer node 10 comprises a second CA-system 1 1 being the customer's own 
CA-system, a second CA-client 18 connected to the CA-system 1 1, an authorization 
module 19 connected to the second CA-client 18 and an authentication module 21 
connected to the authorization module 19. The authentication module 21 could be a 
web-server. In one preferred embodiment it is an https-server. The customer is in this 

30 case not necessarily the owner of the device but rather the owner of the network or the 
one who manages the devices. 
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A number of devices 1 according to the invention are connected to the network. One of 
the devices 1 is shown to comprise an activating client 33 and a communication means 
35. The communication means 35 should be able to crypt/decrypt and sign and possi- 
5 bly verify requests. The communication means 35 is in one embodiment an https- 
proxy. When, for example, an end user or an installation engineer connects the device 
1 to the network and indicates the address to the customer node 10 the activating client 
33 is activated and sends automatically out a request for a new private key, a new cer- 
tificate and a CA-certificate. The temporary private key, which was provided to the 

10 device at the factory, is used to sign the request for a new private key, a new certificate 
and a CA-certificate. This is done in the communication means 35 when the request is 
sent from the device 1 . A factory CA-certificate provided from the first CA-system in 
the factory to the authentication module 21 in the customer node 10 in the network is 
used to verify the request. The temporary private key and the temporary certificate are 

1 5 replaced by a new private key and a new certificate signed by the second CA-system 
1 1 . A CA-certificate is also provided to the device 1 from the second CA-system 1 1 . 
When the device 1 has received and stored the new private key, certificate and CA- 
certificate the customization is completed and the device is tied to the specific cus- 
tomer, which provides the second CA-system 11. The retrieved new private key, cer- 

20 tificate and CA-certificate are then used by the device 1 for secure connections. 



Fig. 3 is a flowchart of one embodiment of a process according to the invention. The 
process will here below be described with reference to Figure 1, 2 and 3. The process 
starts with the manufacturing of one device 1. In block B41 the loading station 4 loads 
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pie of the type of request. The CA-system 5 generates a private and a public key, in- 
cludes the public key in a certificate and signs the certificate in block B44 and in block 
B45 a reply with the private key and the certificate is sent to the first CA-client 3. In 
block B46 the temporary key and certificate are stored in the device 1 . 

5 

The device 1 is then delivered to a customer and in block B47 the device 1 is con- 
nected to an insecure network by, e.g. an end user or an installation engineer. When the 
end user gives the name or address to the customer node 10 the activating client 33 is 
activated and a request for a new private key, certificate and a CA-certificate is sent 

10 out from the activating client 33. This is shown in block B49. It is not necessarily the 
end user who gives the address to the customer node 10. The address could for exam- 
ple be pushed out to the device 1 from another unit or the end user could give the ad- 
dress to another unit, which knows the address of the customer node 10. It is also pos- 
sible that more input data is needed from the end user before the request for a new key 

15 and certificate is sent out. The request is in block B51 sent through the communication 
means 35 for ensuring a secure communication. The request is signed by the commu- 
nication means 35 using the first temporary private key provided at the factory. The 
request is also encrypted by the communication means 35 before leaving the device L 
In block B53 the request is forwarded through the network/s to the customer node 10. 

20 In block B55 the request is received in the authentication module 21, which in this em- 
bodiment is a web-server and in block B57 the web-server 21 uses strong authentica- 
tion to authenticate the device, i.e. verify that the device 1 is produced at the factory. 
The factory CA-certificate has been distributed to the web-server 21 from the factory 
and is used for the authentication. The authentication module 21 also decrypts the re- 

25 quest. If two way authentication is used the authentication module 21 also signs an an- 
swer which is sent back to the device. The communication means 35 uses the CA- 
certificate that optionally was provided to the device 1 at the factory to authenticate the 
customer node. 

30 If the one or optionally the two way authentication was successful the request is for- 
warded to the authorization module 19 in the customer node 10. This is done in block 
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B59 and in block B61 the authorization module 19 first retrieves the identity of the de- 
vice from the temporary certificate and then uses this identity to verify that the device 
has the right to receive keys from this specific CA-server. The authorization module 19 
uses thus an internal database including access control register, where all valid devices 
5 and their identities are listed. Furthermore the authorization module 19 verifies that 
keys have not been distributed to this device before. If the authorization was successful 
the authorization module 19 forwards the request in block B62 to the second CA-client 
18, which forwards the request of a private key, a certificate and a CA-certificate as an 
xml-request to the second CA-system 11. This is shown in block B63. The connection 

10 is done over TCP/IP and it is xml-encoded. The identity of the device is included in the 
request. Other parameters such as the length of the keys, the validity period of the cer- 
tificate, the name of the CA-server, the locality, if the private key should be encrypted 
or not, if a CA-certificate should be included in the answer, organisation, organisation 
unit, email etc. are also optionally included in the xml-request. These parameters and 

1 5 the identity of the device are used for the configuration of the certificate. In block B65 
the second CA-system 1 1 generates a key, a certificate and a CA-certificate and in 
block B67 the second CA-system 1 1 signs the certificates. Thereafter, in block B69, a 
reply comprising a new private key, a new signed certificate and a signed CA- 
certificate is sent from the second CA-system 1 1 to the second CA-client 1 8 and in 

20 block B71 this key and certificates are forwarded through the customer node 10 and 
the communication means 35 to the activating client 33 in the device 1. The reply is 
encrypted in the authentication module 21 and it is decrypted in the communication 
means 35. Finally, in block B73, the device 1 stores the new private key, the new cer- 
tificate and the CA-certificate and thus the old first temporary private key and the first 

25 temporary certificate are replaced. 

If a CA-certificate was provided to the device during the manufacturing this CA- 
certificate is used to verify the respond from the customer node 10. 

30 Fig. 4 is a schematic view of a CA-system according to one embodiment of the inven- 
tion. It comprises a receiving means 81. The receiving means 81 is adapted to receive 
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requests for keys and certificates from the devices. The receiving means 81 should also 
be able to receive the parameters that are used for the configuration of the certificate as 
described above. The receiving means 81 should comprise software to receive the re- 
quest over TCP/IP and also software to understand an xml-request. The CA-system 
5 comprises also answering means 83 adapted to return private keys and signed certifi- 
cates and possibly also CA-certificates over TCP/IP to the devices. The answer is xml- 
encoded. Furthermore it comprises generating means 85 adapted to generate private 
keys and public keys and certificates comprising said public keys together with certain 
parameters. The CA-system comprises furthermore signing means 87 adapted to sign 

10 certificates. The receiving of requests, the generating of keys and certificates and the 
replying to the requests, which replies comprise the generated keys and certificates, is 
done totally automatic. There is no manual treating of the CA-system after the configu- 
ration of the same. One first CA-system 5 is adapted to be located at the factory and a 
second CA-system 1 1 is adapted to be located in the customer network. This second 

1 5 CA-system 1 1 is adapted to return CA-certificates together with the private key and 
certificate to the requesting devices. The CA-system can comprise more than one CA, 
i.e. several CA:s where each CA has its own root-certificate and root-private-key. 

Fig. 5 is a schematic view of a device 1 according to one embodiment of the invention. 

20 It comprises a first CA-client 3 adapted to during the manufacturing request the first 

temporary private key and the temporary certificate from the first CA-system 5 (Fig. 1) 
located at the factory. It comprises also a memory 93 in which the keys and certificates 
are stored. Furthermore it comprises an activating client 33, which is adapted to be ac- 
tivated as soon as the device has been connected to an insecure network by e.g'. an end 

25 user and the address to the customer node 10 has been given. The activating client 33 
is adapted to replace the temporary private key and the temporary certificate stored in 
the device 1 with a new private key, a new certificate signed by the second CA-system 
1 1 (Fig. 2) connected to the network and a CA-certificate. In one embodiment the acti- 
vating client 33 sends out a request through a communication means 35 for a new pri- 

30 vate key, a new certificate and a CA-certificate. The request is sent to the second CA- 
system 1 1 . The communication means 35 ensures that the communication out from the 
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device is secure. It signs and encrypts the request. It also performs decryption of the 
retrieved answers. 

The device 1 can store the private key and the certificate and optionally the CA- 
5 certificate encrypted in the memory 93. 

It has been described that the second CA-system generates the new private key and the 
new certificate. This is not necessary. The private key and the certificate could be gen- 
erated in another unit, which can reach both the device and the CA-system. A further 
10 possible variant is that the device itself generates the private and the public key. These 
two variants are possible as long as the new certificate is signed by the second CA- 
system. 

In another embodiment of the invention a hierarchy of CA-sy stems could be present 
15 instead of the single second CA-system. In this case another CA-system (e.g. Verisign) 
will sign the factory CA-certificate and optionally the customer CA-certificate. The 
device, the authentication module or any module can use a CA-certificate from the 
other CA to perform verification. 

20 The here-described security architecture also makes it possible to protect the private 
key from disclosure in an efficient way. One alternative is to construct the device in a 
way that the device always requires strong authentication. Another alternative is to put 
the private key and certificate in a tamper device inside the device. The private key 
will never leave its protected storage inside the device (like a hard smart card). Both 

25 alternatives provide high security. Furthermore this solution provides a high security 
during the distribution of the keys, since the distribution is done automatically and 
nothing is done manually. 
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CLAIMS 

1 . A method for distributing private keys and certificates to cryptographic devices (1), 
5 characterised in that it comprises the steps of: 

- providing a first CA-system (5) at the manufacture of the devices; 

- providing a temporary private key and a temporary certificate from the first CA- 
system (5) to each device (1) during the manufacture of the device (1); 

- delivering said devices (1) to customers; 

10 - providing a second CA-system (1 1) at a customer node (10), this being performed 
at this process step or earlier in the process; 
for each delivered cryptographic device: 

- connecting the device (1) to a network, which is reachable from the customer node 

(10); 

15 — authenticating the device (1) as being from said manufacture; 

automatically replacing the temporary private key and the temporary certificate 
with a new private key and a new certificate and also automatically providing the 
device with a CA-certificate, the new certificates being signed by the second CA- 
system (11) which is notified of the connection of the device (1) as soon as the de- 

20 vice (1) has connected to the network. 

2. A method according to claim 1, characterised in that it further comprises the steps 
of: 

- loading software, for example a first CA-client, which is adapted to send out a re- 
25 quest for the temporary private key and the temporary certificate to the first CA- 
system (5), in the device (1) by using a loading station (4) provided at the site of 
manufacture during the manufacture; 

- indicating to the device (1) from the loading station (4) that it is time to request a 
temporary private key and a temporary certificate from the first CA-system (5); . 

30 - sending the request from the device (1) to the first CA-system as an xml-(extensible 
mark-up language)-request; 
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- storing the retrieved temporary private key and temporary certificate in the device 

(i). 

3. A method according to claim 1 or 2, characterised in that it further comprises the 
5 steps of: 

- automatically sending out a request for a new private key, a new certificate and a 
CA-certificate from the device to the customer node (10) as soon as the device (1) 
has been connected to the network and the address to the customer node (10) has 

. been provided; 

10 - authenticating the device in an authentication module (21) comprised in the cus- 
tomer node (10) by using a factory CA-certificate provided to the authentication 
module (21) from the first CA-system; 

- if the authentication was successful, forwarding the request to an authorization 
module (19) connected to the authentication module (21), to verify if the request 

1 5 should be allowed and the device (1) should be provided with new keys and certifi- 

cates from the second CA-system (11); 

- if the authorization was successful, forwarding the request to a second CA-client 
(18), which forwards the request as an xml-request to the second CA-system (1 1), 
which is connected to the second CA-client (18); 

20 - answering with a new private key, a new signed certificate and also with a CA- 
certificate from the second CA-system (1 1); 
forwarding the answer to the requesting device (1); 

- replacing the temporary private key and the temporary certificate with the new pri- 
vate key and the new certificate and storing them together with the CA-certificate 

25 in the device (1). 

4. A method according to claim 1 or 2, characterised in that it further comprises the 
steps of: 

- providing the device (1) with a CA-certificate from the first CA-system (5) during 
30 the manufacture; 
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- automatically sending out a request for a new private key, a new certificate and a 
CA-certificate from the device to the customer node (10) as soon as the device (1) 
has been connected to the network and the address to the customer node (10) has 
been provided; 

5 - authenticating the device in an authentication module (21) comprised in the cus- 
tomer node (10) by using a factory CA-certificate provided to the authentication 
module (21) from the first CA-system; 

authenticating the customer node (1 1) in the device (1) by using the CA-certificate 
provided to the device (1) during the manufacture; 
10 - if the authentication in the customer node (11) and the device (1) was successful, 
forwarding the request to an authorization module (19) comprised in the customer 
node (10) to verify if the request should be allowed and the device (1) should be 
provided with new keys and certificates from the second CA-system (1 1); 

- if the authorization was successful, forwarding the request to a second CA-client 
15 (18), which forwards the request as an xml-request to the second CA-system (1 1), 

which is connected to the second CA-client (18); 

answering with a new private key, a new signed certificate and also with a CA- 
certificate from the second CA-system (1 1); 

- forwarding the answer to the requesting device (1); 

20 - replacing the temporary private key and the temporary certificate with the new pri- 
vate key and the new certificate and storing them together with the CA-certificate 
in the device (1). 

5. A method according to any one of the claims 1-4, characterised in that it further 
25 comprises the steps of: 

- sending the request from the device through a communication means (35) provided 
in the device; 

- signing the request in the communication means (35) using the temporary private 
key before it is sent to the customer node (10); 

30 - encrypting the request by the communication means (35) before it is sent to the 
customer node (10); 
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- receiving and decrypting the answers from the second CA-system (1 1) in the com- 
munication means (35). 

6. A method according to any one of the preceding claims, characterised in that it 
comprises decrypting the request in an authentication module (21) when the request 
from the device (1) is received in the customer node (10) and encrypting the answer 
in the authentication module (21) before it is sent to the device (1). 

7. A method according to any one of the claims 1-6, characterised by including the 
identity of the device and optional parameters in the request, this identity and the 
parameters being used in the configuration of the certificate. 

8. A method according to any one of the preceding claims, characterised in that it 
further comprises the steps of: 

- receiving a request for a new private key, a new certificate and a CA-certificate 
from the device (1) in the second CA-system (1 1); 

- generating a new private key, a new public key and configuring a new certificate 
comprising said new public key in the second CA-system (11); 

- signing said new certificate and a CA-certificate in the second CA-system (1 1); 

- automatically answering the request by sending the requested new private key, new 
certificate and CA-certificate to the device (1) from the second CA-system. 

9. A cryptographic device, characterised in that the device (1) is adapted to receive 
a temporary private key and a temporary certificate from a first CA-system (5) pro- 
vided at the manufacture during the manufacture of the device (1) and in that it 
comprises an activating client (33) which is adapted to be activated as soon as the 
device is connected to a network and an address to a customer node (10) has been 
provided, the activating client (33) being adapted to replace the temporary private 
key and the temporary certificate with a new private key, a new certificate and a 
CA-certificate, the certificates being signed by a second CA-system (11) comprised 
in the customer node (10), which is reachable from the network. 
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10. A device according to claim 9, characterised in that the activating client (33) is 
adapted to send out a request for a new private key, a new certificate and a CA- 
certificate through a communication means (35), which is comprised in the device 

5 (1) and connected to the activating client (33), the request being sent to the cus- 

tomer node (10). 

11. A device according to claim 10, characterised in that the communication means 
(35) is adapted to sign and encrypt the request before forwarding it to the customer 

10 node (10), the communication means (35) also being adapted to decrypt the re- 

ceived answers. 

12. A device according to claim 11, characterised in that the communication means 
(35) is a https-proxy. 

15 

13. A device according to any one of the claims 9-12, characterised in that it com- 
prises a first CA-client (3) adapted to request the first temporary private key and 
the temporary certificate from the first CA-system (5). 

20 14. A system used to distribute private keys and certificates to cryptographic devices, 
characterised in that it comprises: 
- a first CA-system (5) located at the manufacture, which first CA-system (5) is 
adapted to^provide the device (1) with a temporary private key and a temporary 
certificate during the manufacture of the device (1); 

25 - a second CA-system (1 1), being the customer's CA-system, located in a customer 
node (10), which is reachable from the device (1) when it has been connected to a 
network by, for example the end user, said second CA-system (11) being adapted to 
provide the device (1) with a new private key, a new certificate which is signed by 
the second CA-system and with a CA-certificate, said new private key and new 

30 certificate being adapted to automatically replace the temporary private key and the 

temporary certificate in the device (1) when the device (1) is being customized; 
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- an authentication module (21) being adapted to verify that the device (1) has been 
produced at said manufacture by using a factory CA-certificate provided to the 
authentication module (21) from the first CA-system (5). 

5 1 5. A system according to claim 14, characterised in that the authentication module 
(21) is provided in the customer node (10) and is connected to the second CA- 
system (1 1) through an authorization module (19), which is adapted to verify if the 
request is allowed, and through a second CA-client, which is adapted to transform 
the request into an xml-request and forward it to the second CA-system (11). 

16. A system according to claim 14 or 15, characterised in that the authentication 
module (21) is a https-server. 

17. A system according to any one of the claims 14-16, characterised in that it com- 
15 prises a communication means (35), which is located in the device (1) and is 

adapted to sign and encrypt the request before it is sent to the customer node (10) 
and decrypt and optionally verify the retrieved answer. 

18. A system according to any one of the claims 14-17, characterised in that the sys- 
20 tern comprises a loading station (4) at the site of manufacture, which loading sta- 
tion (4) is adapted to load the necessary software, for example a first CA-client (3), 
which is adapted to send out a request for a temporary private key and a temporary 
certificate to the first CA-system (5), to the device (1) during the manufacture and 
also to indicate for the device (1) when it should send out the request to the first 

25 CA-system (5). 
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invention the method comprises the steps of: providing a first CA-system (5) 
at the manufacture of the devices; providing a temporary private key and a 
temporary certificate from the first CA-system (5) to each device (1) during 
the manufacturing of the device (1); delivering said devices (1) to 
customers; providing a second CA-system (1 1) at a customer node (10), this 
being performed at this process step or earlier in the process; for each 
delivered cryptographic device: connecting the device to a network, which is 
reachable from the customer node (10); authenticating the device as being 
from said manufacture; automatically replacing the temporary private key 
and the temporary certificate with a new private key and a new certificate 
and also automatically providing the device with a CA-certificate, the new 
certificates being signed by the second CA-system (11) which is notified of 
the connection of the device (1) as soon as the device (1) has connected to 
the network. 
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